The present disclosure relates generally to computer-based modeling and, in particular, to management of component coupling in an object-centric process implementation.
Most existing languages for process modeling (e.g., Business Process Modeling Notation (BPMN)) and implementation (e.g., Business Process Execution Language (BPEL)) are activity-centric, since they represent processes as a set of activities connected by control-flow elements to indicate the order of activity execution. In recent years, however, a line of alternative object-centric approaches for modeling and implementing business processes has been proposed, which includes artifact-centric modeling, adaptive business objects, data-driven modeling, and proclets. Activities in the process are distributed among several components, each representing an object life cycle that defines possible states of a particular object and transitions between these states. Interaction among such object life cycle components ensures that the overall process logic is correctly implemented.
Object-centric implementations can be used for distributed process execution and can lead to a more maintainable and adaptable implementation than activity-centric approaches, since behavior of one object can be partially changed without influencing the rest of the process. However, the greater the number of dependencies and interactions between the object life cycle components, the more costly becomes their distribution and the more complicated it is to change their behavior. One of the challenges in object-centric process implementation is, therefore, the management of component interdependencies, commonly referred to as “coupling” in software engineering. Existing approaches do not seem to address this problem directly. For example, artifact-centric modeling describes properties of objects that should be associated with life cycles to distinguish them from other objects. Life cycles are derived for those objects that change state in a given process model. These methods of identifying components run the risk of producing components that are highly coupled. Refactoring the components is one approach to reducing coupling.
What is needed, therefore, is a way to determine, or predict, the coupling of object-centric process implementations prior to deriving the implementations.